home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
- INTERNET DRAFT Nov 1992
-
-
- Postmaster Convention for X.400 Operations
-
- Sat Nov 14 21:58:15 CST 1992
-
-
- C. Allan Cargille
- University of Wisconsin
- Allan.Cargille@cs.wisc.edu
-
-
-
-
-
- This draft document is being circulated for comment.
-
- If consensus is reached it may be submitted to the RFC
- editor as a Proposed Standard protocol specification, for
- use in X.400 in the Internet.
-
- Please send comments to the author, or to the IETF OSI X.400
- Operations Working Group mailing list
- <ietf-osi-x400ops@cs.wisc.edu>.
-
- The following text is required by the Internet-draft rules:
-
- This document is an Internet Draft. Internet Drafts
- are working documents of the Internet Engineering
- Task Force (IETF), its Areas, and its Working
- Groups. Note that other groups may also distribute
- working documents as Internet Drafts.
-
- Internet Drafts are draft documents valid for a
- maximum of six months. Internet Drafts may be
- updated, replaced, or obsoleted by other documents
- at any time. It is not appropriate to use Internet
- Drafts as reference material or to cite them other
- than as a "working draft" or "work in progress."
-
- Please check the I-D abstract listing contained in
- each Internet Draft directory to learn the current
- status of this or any other Internet Draft.
-
- Abstract:
-
- Both RFC822 and 1173 (Host Requirements) require that
- the email address "postmaster" be supported at all
- hosts. This paper extends this concept to X.400 mail
- domains which have registered RFC1327 mapping rules
- (and therefore which appear to have normal RFC822-style
- addresses).
-
-
-
-
-
- Cargille Expires May 18, 1993 [Page 1]
-
-
-
-
-
- DRAFT X.400 Postmaster Convention Nov 1992
-
-
- 1. Postmaster Convention in RFC822
-
- Operating a reliable, large-scale electronic mail (email)
- network requires cooperation between many mail managers and
- system administrators. As noted in RFC822 [1], often mail
- or system managers need to be able to contact a responsible
- person at a remote host without knowing any specific user
- name or address at that host. For that reason, both RFC822
- and the Internet Host Requirements [2] require that the
- address "postmaster" be supported at every Internet host.
-
- 2. Postmaster Convention and X.400
-
- However, RFC822 is not the only email protocol being used in
- the Internet. Some Internet sites are also running the
- X.400 (1984) email protocol [3]. In the near future, the
- 1988 X.400 protocol is also expected to be in use [4].
- RFC1327 specifies how to map between X.400 and RFC822
- addresses [5]. When mapping rules are used, addresses map
- cleanly between X.400 and RFC822. In fact, it is impossible
- to determine by inspecting the address whether the recipient
- is an RFC822 mail user or an X.400 mail user.
-
- A paper by Rob Hagens and Alf Hansen describes an X.400
- community known as the "Global Open MHS Community" (GO-MHS)
- [6]. Many mail domains in the GO-MHS Community have
- registered RFC1327 mapping rules. Therefore, users in those
- domains have RFC822-style email addresses, and these email
- domains are a logical extension of the RFC822 Internet. It
- is impossible to tell by inspecting a user's address whether
- the user receives RFC822 mail or X.400 mail.
-
- Since these addresses appear to be standard RFC822
- addresses, mail managers, mailing list managers, host
- administrators, and users expect to be able to simply send
- mail to "postmaster@domain" and having the message be
- delivered to a responsible party. When an RFC1327 mapping
- rule exists, the X.400 address elements corresponding to the
- left-hand-side "postmaster" are "Surname=Postmaster" (both
- 1984 and 1988) and "CommonName=Postmaster" (1988 only).
- However, neither the X.400 protocols, North America X.400
- Implementor's Agreements [7], nor the European X.400
- Implementor's Agreements [8] require that
- "Surname=Postmaster" and "CommonName=Postmaster" be
- supported. (Supporting these addresses is recommended in
- X.400 (1988)).
-
- For mapped X.400 domains which do not support the postmaster
- address(es), this means that an address such as
- "user@some.place.zz" might be valid, yet mail to the
- corresponding address "postmaster@some.place.zz" fails.
- This is frustrating for remote administrators and users, and
- can even prevent operational problems from being
-
-
- Cargille Expires May 18, 1993 [Page 2]
-
-
-
-
-
- DRAFT X.400 Postmaster Convention Nov 1992
-
-
- communicated and resolved. In this case, the desired
- seamless integration of the Internet RFC822 mail world and
- the mapped X.400 domain has not been achieved.
-
- The X.400 mail managers participating in the Cosine MHS
- Project discussed this problem in a meeting in June 1992
- [9]. The discussion recognized the need for supporting the
- postmaster address at any level of the address hierarchy
- where these are user addresses. However, in the end, the
- Cosine MHS Managers only recommended support of the
- postmaster address Surname and Common Name at all levels of
- the address hierarchy down to the Organization level--that
- is, only for addresses of the form
-
- C=xx; ADMD=someadmd; S=postmaster
- C=xx; ADMD=someadmd; O=org; S=postmaster
- C=xx; ADMD=someadmd; PRMD=someprmd; S=postmaster
- C=xx; ADMD=someadmd; PRMD=someprmd; O=org; S=postmaster
-
-
- While there is value in supporting postmaster addresses down
- to the Organization level, this does not solve the entire
- problem of consistent email management between the Internet
- RFC822 world and mapped X.400 mail domains. Specifically,
- there are cases where a user's RFC822-style address maps
- into an X.400 address containing attributes below
- Organization, such as Organizational Units. Again, RFC822
- community members have no idea what the X.400 representation
- of the address is, nor should they need to know. However,
- they expect that if they can send mail to (for example)
- "user@some.place.zz", then they should also be able to mail
- "postmaster@some.place.zz". If they cannot, then the
- desired seamless integration of the X.400 and RFC822 mail
- worlds has not been realized, and the quality of service has
- broken down.
-
- 3. Proposed Solution
-
- To fully achieve the desired seamless integration of email
- domains for which RFC1327 mapping rules have been defined,
- the following convention must be followed,
-
- If there are any valid addresses of the form
- "user@domain", then the address "postmaster@domain"
- must also be valid.
-
- To express this in terms of X.400: For every X.400 domain
- for which an RFC1327 mapping rule exists, if any address of
- the form
-
- Surname=User; <Other X.400 Address Elements>
-
- is a valid address, then the address
-
-
- Cargille Expires May 18, 1993 [Page 3]
-
-
-
-
-
- DRAFT X.400 Postmaster Convention Nov 1992
-
-
- Surname=Postmaster; <Same X.400 Address Elements>
-
- must also be a valid address. If the X.400 system is
- running X.400(1988), then the address
-
- CommonName=Postmaster; <Same X.400 Address Elements>
-
- must also be supported.
-
- To remain consistent with RFC822, "Mail sent to that address
- is to be routed to a person responsible for the site's mail
- system or to a person with responsibility for general site
- operation." [10]
-
- 4. References
-
- [1] RFC822
-
- [2] RFC1173
-
- [3] X.400 (1984)
-
- [4] X.400 (1988)
-
- [5] RFC1327
-
- [6] presently draft-ietf-x400ops-mgtdomains-ops-02.txt
-
- [7] NIST X.400 Implementors Agreements
-
- [8] EWOS X.400 Implementors Agreements
-
- [9] Minutes from June 1992 Cosine MHS Managers Meeting
-
- [10] RFC822, direct quote
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Cargille Expires May 18, 1993 [Page 4]
-